智能体:创建、管理与自动扩编
把 AI 拆成一支有岗位、有技能、有负责人的队伍,并让系统替你盯着"现在该不该加人"。
你在前面几章已经把公司建好、项目开起来、预算设好、资料导进来。现在到了一个关键问题:这些活到底是谁在干?
答案不是"一个大模型在干所有事",那样既管不好、也追不了责。ZY 引擎的做法,是把干活的 AI 拆成一个个智能体(Agent)——每个智能体有自己的岗位、自己的技能、自己的负责人,就像一家公司里的员工一样,只不过他们是数字的。
先给你一个明确的结论,后面再用整章去论证它:系统能自动感知业务变化、自动给出"该加人了"的建议,甚至能一键把新员工招进来、配好技能、做完上岗测试;但"要不要加人"这个决定,始终由你拍板。它不会背着你偷偷扩编、偷偷花钱。这不是能力不足,这是刻意设计——组织变动和成本变化,必须让人知道、让人同意。
你将学会
- 分清"管理者智能体"和"员工智能体",知道谁该下活、谁不该下场
- 在「智能体中心」把四个标签页(组织 / 任务 / 配置 / 运行)各管什么看明白
- 从岗位模板库挑一个岗,完整创建一个 Agent 并绑定技能
- 在「组织进化」页读懂 AI 建议,并且敢点「确认」或「暂缓」
- 知道四阶段(起步 / 成长 / 规模化 / 成熟)分别是多大规模、大概多少钱
先纠正一个常见误解
很多新用户以为:"我买了 AI,它就是一个超级大脑,我在对话框里说一句,它就把所有活干完了。" 在演示场景下这听上去很美,但一旦你的项目真的跑起来,就会立刻遇到三个问题:
问题一:追不了责
一个大脑什么都做,出了错你不知道是"需求理解错了"还是"执行做砸了",也没法针对性地换人、换技能。
问题二:管不了成本
一个大脑什么活都接,你没法说"营销这块预算给多一点、客服这块省一点",因为根本没有"块"。
问题三:长不大
业务从 1 个项目扩到 10 个项目,一个大脑处理不过来,你也没法给它"加人",只能干等它变慢。
所以 ZY 引擎选择把 AI 组织化。每个智能体都遵守「三要素」:
| 三要素 | 是什么 | 在界面哪里配 | 人话解释 |
|---|---|---|---|
| 专家(岗位) | 这个 Agent 是什么岗位、负责什么、红线在哪 | 智能体中心 → 组织 →「新建 Agent」的岗位角色 / 职责边界 / 人工红线 | 相当于员工入职时的"岗位说明书" |
| 技能(Skill) | 这个岗位会哪些具体本事(前端编码、投放、写文案……) | 智能体中心 → 组织 → 成员列表的「技能」按钮;技能库在上方统一维护 | 相当于员工的"技能证书",可版本化、可复用 |
| 连接器(Connector) | 这个岗位能操作哪些外部系统(飞书、邮件、Git 仓库……) | 岗位模板里登记;运行时按最小权限授权 | 相当于员工的"门禁卡",给哪张卡就能进哪扇门 |
一、Agent 是什么,跟"任务"什么关系
先把两个最容易混的概念分清楚:Agent(智能体)是"人",任务(Task)是"活"。
任务是你或者管理者 Agent 派下去的一件具体工作,比如"写一篇产品发布文案""调研三个竞品的定价"。任务有标题、有类型、有优先级、有状态(待处理 / 执行中 / 已完成……)。而 Agent 是承接这些活的"员工"——它可能今天接一个文案任务,明天接一个调研任务。
那么,任务是怎么落到某个 Agent 头上的?这里就出现了两类 Agent。
管理者 Agent 与员工 Agent
| 类型 | 界面显示 | 职责 | 会不会下场执行 |
|---|---|---|---|
| 管理者 | 管理者 | 识别任务、把任务分给合适的员工、跟踪进度、做质量验收 | 不会。它只协调分配,不亲自写代码、不亲自发邮件 |
| 员工 | 员工 | 各领域的专家,真正把活干出来 | 会。它是具体任务的执行者 |
"管理者不下场"这条规则不是随便定的。它的意义在于:分工和验收必须是两拨人。如果同一个 Agent 既分活给自己、又给自己的活打分,那"质量把关"就是一句空话。所以引擎在底层会拦:只有管理者类型的 Agent 才能调用"分配任务"能力,员工去调会被直接拒绝,界面上的报错是「agent xxx is not a manager」。
管理者怎么给员工派活
当一个管理者 Agent 接到任务,它按这个顺序挑人(这套逻辑在代码里是真实执行的,不是文案):
- 识别任务:看任务的类型(构建 / 市场 / 财务 / 内容 / 客服等),映射到候选岗位。
- 匹配员工:在同一个项目里,找岗位匹配、且状态是"正常"的员工 Agent。
- 择优分配:看候选员工最近 30 次任务的平均质量分,挑分高的。
- 产出分配路径:记下"某某经理 → 某某员工",供后续绩效追踪和复盘。
最后这一步的"分配路径"很关键,它是后面「沉淀飞轮」的数据来源——哪个员工被派了什么活、干得怎么样,都会被记下来,越用越准。
跟第 09 章"任务"的边界在哪
本章讲的是"人"(Agent 怎么建、怎么配、怎么扩编);第 09 章讲的是"活"(任务怎么派、轮次怎么转、验收怎么做)。两者的交界点是:任务可以选择"交给哪个岗位",Agent 则决定"这个岗位由谁来干"。如果你现在看不懂任务那一侧,没关系,先记住本章的"人"怎么配齐,第 09 章会接上。
两种执行方式:loop 引擎与 agent 引擎
智能体干活时,底层有两种"工作方式",你可以理解为两种工人:
loop 引擎(默认)
派一个"外部工人"(qianshou 循环工具)去跑。适合复杂、编码类、耗时长的任务,比如开发一个功能、跑一整个软件工程。它是默认真选。
agent 引擎
系统内部直接调用 AI 完成。适合信息整合、接口调用、快速的任务,比如汇总一份资料、查一个数据。
选哪个由三层配置决定,优先级从高到低是:任务级 > 角色级 > 项目默认。也就是说,单条任务可以指定引擎;没指定就看这个角色的配置;再没配就用项目的默认值。你不需要一开始就操心这件事,默认值对绝大多数场景是对的。
进阶:系统怎么判断一个任务该用哪个引擎?
在你没明确指定时,系统会按任务描述里的关键词做启发式预测:出现"编码、开发、构建"等词倾向 loop;出现"查询、汇总、快速"等词倾向 agent;实在判断不出来,兜底走 loop。这套预测只是"没得选时的默认",有明确配置时永远以配置为准。
二、智能体中心:四个标签页各管什么
所有的"人"都在一个地方管:智能体中心。
页面顶部是标题「智能体中心」,下面四个标签页:组织 任务 配置 运行。很多人第一次进来只看了"组织"就退出了,其实另外三个页签才是日常管理的重心。
标签页一:组织——看队伍、建人、配技能
这是默认打开的页签,从上到下有三块。
第一块:Agent 组织(管理者 → 员工)。标题右侧有 刷新 和 新建 Agent 两个按钮。下面是组织架构树,把管理者挂在上面、员工挂在下面,一眼看清谁领导谁。
第二块:成员列表。用表格列出所有 Agent:
| 列名 | 内容 | 怎么读 |
|---|---|---|
| 名称 | 你给 Agent 起的名字,如"项目经理小 Z" | 自己起,随意 |
| 岗位 | 岗位标识,如 manager、fullstack_dev | 决定它接哪类活 |
| 类型 | 管理者 / 员工 | 决定它能不能分配任务 |
| 状态 | 正常 / 停用 / 暂停 | 停用的 Agent 不会被派活 |
| 操作 | 详情 技能 暂停 或 启用 | 详情看画像与绩效;技能改装配;暂停/启用控制是否在线 |
第三块:岗位模板库 + 技能库,左右并排。岗位模板库告诉你"这个项目类型下有哪些标准岗位可选",技能库是"这些岗位能用哪些技能"。这两块是给前两块供料的,下面两节专门讲。
标签页二:任务——给智能体派活的另一个入口
标题是「Agent 任务编排」,三个按钮:刷新、目标拆解、新建任务。
「目标拆解」是你给一个宏观目标(比如"为本季度新品做一轮获客"),AI 自动拆成 3~8 个子任务排队。「新建任务」是手动建一条具体任务。任务列表的列有:标题、类型、优先级、状态、岗位、创建时间、操作。
每行任务根据状态显示不同按钮:
| 按钮 | 什么时候出现 | 点了会怎样 |
|---|---|---|
| 日志 | 任何时候 | 抽屉打开,看这条任务的执行日志 |
| 注入 | 任何时候 | 把新信息补进正在跑的任务里(比如临时补一句"重点是海外客户") |
| 暂停 | 任务"执行中" | 任务转到"已暂停"。注意:当前这一轮会跑完才停,不会硬杀进程丢上下文 |
| 恢复 | 任务"已暂停" | 重新排队继续 |
| 通过 / 拒绝 | 任务"待审批" | 人工确认放行或驳回。驳回会让任务转失败并记下原因 |
任务状态一共六种,界面中文如下:待处理 执行中 已完成 失败 已暂停 待审批。
「新建任务」弹窗的字段:标题(必填)、描述、类型(构建 build / 研究 research / 内容 content / 评审 review / 市场 market / 财务 finance)、优先级(1–10)、岗位角色(可选,填了会定向派给这个岗位)、知识库(逗号分隔的知识库 ID)。「目标拆解」弹窗只要两个输入:目标、项目背景(可选)。
标签页三:配置——决定每个 Agent 用什么模式、什么提示词跑
标题「Agent 运行配置」。按钮:刷新、只看启用(开关)、导入 XML、新建配置。
配置表列:Agent 名称、角色、运行模式、Cron、工具、启用、版本、操作。运行模式有四种:
| 模式 | 什么时候用 | 要注意 |
|---|---|---|
| 前台 (foreground) | 你点了它就跑,跑完给你结果 | 适合手动触发的短任务 |
| 后台 (background) | 丢到后台慢慢跑,不占你的界面 | 适合耗时任务 |
| 定时 (cron) | 按 Cron 表达式周期性跑,如每天早 8 点发日报 | 要填「Cron 表达式」,如 0 * * * * |
| 事件监听 (event_listen) | 某类事件发生就触发,如收到客户消息就跑客服 Agent | 要选「事件触发」通配符,如 message.* |
「导入 XML」是用来批量导入 Agent 配置的,弹窗里可以填服务器上的「文件路径」,也可以直接粘贴「XML 内容」,二选一。同一个 name+role 再次导入会变成"版本 +1",不会重复创建。
这块的完整字段说明,见本章 附录 C · Agent 配置字段字典。新手建议:这一页先只改「系统提示词」和「工具列表」,其它保持默认。
标签页四:运行——看谁在跑、花了多少钱
这里有两张表。上面是运行中 Agent 状态:Agent ID、名称、状态(已停止 / 启动中 / 空闲 / 忙碌)、当前运行、上次运行。下面是运行记录:Agent、触发模式、状态、Token、费用(¥)、耗时、创建时间、详情、停止。
右上角有 刷新 和 启动运行。点「启动运行」会让你选:Agent(必填)、任务目标(必填)、触发模式、是否"阻塞等待"。勾了阻塞等待,页面上就会一直等到跑完才返回结果;不勾,丢后台立刻返回。
三、创建一个 Agent:从挑岗到绑定技能
下面是一次完整的创建流程。跟着走一遍,你就掌握了。
- 进入智能体中心 →「组织」页签 → 点右上角 新建 Agent。
- 在弹窗里填「名称」,比如"项目经理小 Z"。这是给人看的名字,怎么起都行。
- 选「岗位角色」。下拉里是这个项目类型下的标准岗位(如 全栈开发专家(fullstack_dev))。这个下拉可以自己输入新岗位,找不到就用岗位模板库里的 key。
- 选「类型」:管理者 或 员工。派活的人选管理者,干活的人选员工。
- (可选)选「上级管理者」:如果这是个员工,把它挂到某个管理者下面,组织树才会好看。
- 填「负责人」。这是必填项,placeholder 写着「owner_id(人类用户或上级管理者 ID)」。填错了直接创建失败,报错「owner_id is required」。
- (可选)填「角色描述」「职责边界」「人工红线」。这三项是给 AI 看的"岗位说明书"。
- 点 创建。成功后列表里就多了一个 Agent。
- 回到成员列表,点这个 Agent 的 技能 按钮,为它勾选技能。
新建弹窗的字段清单
| 字段 | 必填 | 说明 | 填错能改吗 |
|---|---|---|---|
| 名称 | 是 | 展示名,最长 128 字 | 目前界面没有改名入口,建议起一个稳妥的名字 |
| 岗位角色 | 是 | 决定它接哪类活,可从下拉选或自己输入 | 同样建议一次选对 |
| 类型 | 是 | 管理者 / 员工,二选一 | 创建时一次定 |
| 上级管理者 | 否 | 挂在谁下面 | 可选,可不填 |
| 负责人 | 是 | 人类用户 ID 或上级管理者 ID | 可用「转移负责人」换(见负责人手册) |
| 角色描述 | 否 | 这个岗位是干什么的 | 可后续编辑 |
| 职责边界 | 否 | 它能做和不能做的范围 | 可后续编辑 |
| 人工红线 | 否 | 绝对不许碰的底线 | 可后续编辑 |
绑定技能:注意"全量替换"语义
点成员列表里的 技能,弹出「绑定技能 · 某某」的窗口,里面是「选择技能」多选框,提示语是「选择要绑定的技能(每个取最新版本)」。保存后生效。
Agent 详情:看画像,也看绩效
点 详情,弹窗分三段:
- 基本信息:agent_id、岗位、类型、状态、负责人、上级、角色描述、职责边界、人工红线。
- 已绑定技能:列出 skill_id、版本、绑定时间。
- 绩效汇总:平均质量分、任务数、返工率(保留一位小数)、主要返工原因。
「返工率」这一项值得你每次上线新 Agent 后回来看一眼。它统计的是"这个 Agent 交出的活被退回重做的比例"。一个新 Agent 刚上岗时返工率偏高是正常的,随着经验沉淀会下降;如果一个 Agent 跑了很久返工率还居高不下,说明它的岗位画像或技能配置有问题,该调整了。
四、岗位模板库:不用从零想岗位
「我要建一个 AI 团队,可是该有哪些岗位?」这个问题不用你自己想。ZY 引擎按项目类型预置了成套的岗位模板,你直接挑就行。
位置:智能体中心 →「组织」页签 → 下方左侧的「岗位模板库」卡片。顶部有分类筛选:软件开发 / 电商运营 / 内容创作 / 智能制造 / 通用。右侧有 新增模板。
表格列出每个模板的:岗位 key(如 fullstack_dev)、名称(如 全栈开发专家)、技能(这个岗位预置会哪些技能)、操作(详情 删除)。
五类项目分别有哪些岗位
| 项目类型 | 预置岗位 | 典型岗位数 |
|---|---|---|
| 软件开发 software | 项目经理、全栈开发专家、测试专家、运维专家 | 4 |
| 电商运营 ecommerce | 运营总监、营销获客专家、客服专家、数据分析师 | 4 |
| 内容创作 content | 内容总监、文案专家、设计专家、SEO 专家 | 4 |
| 智能制造 manufacture | 生产总监、工艺工程师 | 2 |
| 通用 general | 没有预置库,回退为"项目经理 + 通用执行者"两人最小集 | 2(回退) |
完整的岗位画像(角色描述 / 职责边界 / 人工红线 / 技能 / 连接器),见本章 附录 A · 预置岗位模板全表——这张表可以打印出来对照着建团队。
新增、编辑、删除模板
点 新增模板 会弹出表单,字段:岗位分类(已由你当前选的分类锁定)、岗位 key(必填,提示「如 fullstack_dev(唯一标识,创建后不可改)」)、角色名称(必填)、角色描述、责任边界、人类红线、技能(多选)、连接器(可输入后回车添加)。
点某一行的 详情,可以编辑并保存。详情弹窗底部还有「版本管理」区:可以把当前模板「保存为版本」,列出历史版本,并支持 回滚。
五、技能库与技能装配
岗位模板告诉你"这个岗该会什么",技能库则是这些"本事"本身。位置:智能体中心 →「组织」页签 → 下方右侧的「技能库」卡片。
技能库的列怎么看
| 列名 | 含义 |
|---|---|
| 名称 | 技能的中文名,如"后端编码" |
| skill_id | 技能的唯一标识,如 coding_backend。岗位模板里引用的就是它 |
| 版本 | 同一个 skill_id 可以有多个版本,这里显示最新版 |
| 分类 | 如 coding / marketing / analysis |
| 范围 | 组织级(跨项目复用)或 项目级(只在本项目用) |
| 状态 | 启用 / 禁用 开关,直接拖动即可切换 |
| 操作 | 编辑(存为新版本)、提升为组织级 |
编辑技能 = 存一个新版本
点 编辑,弹窗里有:skill_id(只读)、名称(必填)、分类、提示词、完整定义 JSON、变更说明。底部按钮是 保存为新版本。
注意这个按钮的措辞——它不会覆盖旧版本,而是递增出一个新版本。旧版本还在,这样你随时能对比"这次改动到底带来了什么"。绑定技能的 Agent 会在下次绑定时取到最新版。
把好技能"提升为组织级"
项目级技能只在本项目可见。如果某个技能做得好、你想让它在公司所有项目里复用,点 提升为组织级。确认文案是:
按钮是 申请提升。注意这里是"申请",不是"立即生效"。系统会创建一个人工确认节点(强人工级别),需要人点确认后才真正落库。成功后界面提示「提升申请已提交,待人工审批确认后生效」。
进阶:为什么"提升为组织级"要人工确认?
因为组织级技能是跨项目共享的资产。一旦提升,别的项目也会用到它——影响面超出了你当前这个项目。这类"影响别的项目"的动作,引擎一律走人工确认,避免一个项目里的临时改动悄悄污染全公司。
技能成熟度:目前界面上看不到
设计上,每个技能会有一个"成熟度"等级(学习中 → 练习中 → 熟练 → 专家 → 大师),随成功使用次数和成功率进阶。但要注意:这套成熟度统计需要"技能使用埋点",而当前版本执行链路还无法可靠归因到具体技能,所以成熟度相关的展示与自动进阶属于规划中的能力,你在界面上一时看不到它。别去找"技能成熟度"这个按钮——现在没有。
- 先看岗位模板预置的技能 ID,照着建技能,减少命名混乱
- 技能改名走"存为新版本",保留历史
- 通用性强、验证有效的技能,才去申请提升为组织级
- 不要指望技能库一打开就是满的,它是用出来的
- 不要为了"看起来专业"给新 Agent 一口气绑十几个技能
- 不要找"技能成熟度"进度条,该能力尚未提供界面
六、运行配置(RunConfig):让角色自己决定怎么跑
前面讲了 Agent 的"人"(组织页签)和"活"(任务页签)。还有一个层面是"这个角色的运行参数"——它用什么模型、带哪些技能、输出什么格式、权限多大。这些统称运行配置。
对普通用户来说,你主要会在两个地方接触它:「Agent 运行配置」(配置页签)和「角色管理页」的版本列表。
一个角色级配置大致包含这些字段(人话版):
| 字段 | 人话解释 | 新手要不要改 |
|---|---|---|
| Prompt(提示词) | 这个角色的"工作指令",告诉它怎么思考、怎么输出 | 要改,这是最值得你花时间的 |
| Engine(引擎) | loop 还是 agent(见第一章) | 先别改,用默认 |
| EnabledSkills(启用技能) | 这个角色装配了哪些技能 | 通过「绑定技能」改,别直接改这里 |
| DisabledSkills(禁用技能) | 明确排除的技能 | 先别改 |
| OutputFormat(输出格式) | 要求它输出 markdown / json 等 | 有明确需求再改 |
| CLIParams(命令行参数) | 给 loop 引擎的额外参数 | 别改,进阶内容 |
| PermissionMode(权限模式) | auto-run(自动执行)或 approve(需审批) | 保持审批,见下方警告 |
| Model(模型) | 这个角色用哪个模型档位 | 一般交给模型路由自动决定 |
| MaxBudgetUSD(预算上限) | 这个角色单次/单周期的花费上限 | 按需设 |
| KBIDs(知识库) | 这个角色能检索哪些知识库 | 按需设 |
approve 表示"敏感操作要人点确认",auto-run 表示"自动执行、不等人"。项目级默认是审批模式。不要为了图省事把它切到 auto-run。让 AI 未经确认就自动发邮件、自动改生产数据,风险远大于你省下的那几次点击。
配置也能整批导入。「导入 XML」弹窗支持填服务器路径或直接粘贴 XML 内容,适合同一套配置要批量铺到多个 Agent 的场景。
七、角色进化:让岗位自己变得更好
「角色管理」是自动运营控制台下的一块,专门管"岗位这个角色本身怎么进化"。入口:
页面标题「角色管理」,有三块内容。
第一块:岗位能力图谱
按分类展示"岗位 → 技能"的对应关系,标题右侧有 刷新图谱。一眼看清每类项目里有哪些岗位、每个岗位配了哪些技能。空态是「暂无能力图谱数据」。
第二块:角色列表与版本
角色列表列:角色名称、类型、活跃版本(显示成 vN)、状态(激活 / 未激活)、试跑统计(N 次 / 成功 N / 均成本 ¥N)。每行有 版本 和 优化 两个按钮。
点 版本,下方展开该角色的版本列表:版本号、引擎、版本说明、平均成本、状态、试跑次数、操作(启用)。
版本有三种状态,这是本节的核心概念:
| 状态 | 界面显示 | 含义 |
|---|---|---|
| candidate | 候选 | 新生成的版本,还在试跑,没正式上岗 |
| active | 激活 | 当前生效的版本,Agent 就按它跑 |
| retired | 已停用 | 被淘汰的版本,留档但不生效 |
点 优化,会请求"为这个角色生成一个优化版本"。系统会基于它积累的经验,产出一个 candidate 版本,跑几轮试跑后,如果新版本的成功率不低于老版本、成本没有明显上涨,就会自动提升为 active(这套灰度比较是自动的:最少试跑 5 次、成本容忍 1.2 倍、成功率容差 0.05)。你也可以手动点「启用」直接切到某个版本。
第三块:经验沉淀
这是角色进化的"粮食"。表格列:来源、经验内容、关联任务、时间。空态「暂无经验沉淀」。
经验有四种来源:任务(task)、用户回复(user_reply)、手动(manual)、SOP(sop)。
右上角两个按钮:生成 SOP 草稿 和 新增经验。「新增经验」弹窗字段:来源、关联任务(可选)、经验内容(提示「执行摘要 / 踩坑 / 有效方法」)。保存后提示「经验已沉淀」。
「生成 SOP 草稿」会基于这个角色的历史经验,用 AI 草拟一份标准作业流程,弹窗「SOP 草稿预览」里以 JSON 呈现,你可以查看后决定怎么用。
绩效指标怎么读
角色好不好,看四个数:
这四个数综合成一个绩效分,决定这个角色在"择优分配"里的优先级,也决定优化建议怎么给。你不需要去算这个分,只要知道:成功率是第一位、成本效率第二、返工率第三、经验积累第四。
绩效漏斗:从任务到优化
八、能不能自动管理?——组织进化引擎
这是本章的核心问题,也是整个 ZY 引擎最与众不同的能力。先给结论,再讲细节。
入口与页面
页面标题「组织进化」,右上角两个按钮:阶段切换 和 刷新。页面从上到下是五块卡片:阶段状态、组织架构、AI 建议、能力开启、定量调控。
第一块:阶段状态——我现在处于哪个阶段
卡片显示三样东西:当前阶段徽章、成熟度(未达成 / 接近 / 已达成)、一段 reason 说明。旁边有 重新评估 按钮。
下面有一个可折叠的「判定证据」表:指标 / 当前值 / 阈值 / 是否命中 / 数据是否可用。这张表是"为什么系统说你到了这个阶段"的证据链,非常值得点开看一眼。
第二块:组织架构树
把当前项目里的组织节点画成树。每个节点显示:月成本、负载、成功率、产出数。部门节点会带上警告标记便于辨认。
这棵树和智能体中心的组织树是同一份数据,只是视角不同:智能体中心更偏"人"(谁的岗位、谁的技能),组织进化页更偏"经营"(每个岗位花了多少钱、干了多少活、成了多少)。
第三块:AI 建议——本页最重要的区域
卡片标题是「AI 建议(N 条待处理)」。每条建议包含:
- 类型:增员(role_add)/ 扩容(scale_out)/ 技能装配(skill_attach)/ 阶段升级(stage_upgrade)
- 优先级:建议 / 可选
- 详情折叠:「职责边界 / 技能草稿 / 成本估算」,含估算月成本、扩编后总成本变化
- 「为什么(证据)」折叠:对标 / 指标 / 当前值 / 阈值 / 是否命中
- 操作:确认 暂缓 拒绝
三种操作的确认文案(界面原文):
暂缓的默认天数是 7 天,冷却期内同一条建议不会再反复打扰你。拒绝时填的原因会留档,供后续复盘。这些建议状态在列表里显示为:待确认 / 已确认 / 已应用 / 已拒绝 / 暂缓 / 已过期。
一键扩编:点了「确认」之后发生了什么
这是最"神奇"的一步,但过程并不神秘,它是一串编排好的动作:
- 校验:角色名是否唯一、技能是否合法、预算是否覆盖得住。
- 建角色:引用岗位模板新建一个 Agent,自动归属负责人。岗位模板按项目分类 + 岗位 key精确匹配,不会再出现"软件项目的 manager 套用了电商模板"这种事。如果是"新增岗位"建议,而同一分类下已经有同名角色,会直接拒绝并明确报错;如果是"扩容"建议(给既有岗位加并行实例),才会自动加序号后缀(如"全栈开发专家-2")。你双击确认也不会建出两个同名角色——第二次会被拦下并返回明确提示。
- 写组织节点:把它挂进组织树。
- 装配技能:按建议里的技能草稿绑定。注意:草稿里的技能如果在技能库里不存在,会被跳过并留提示,不会整条失败。
- 入职建档:生成岗位档案。
- 上岗测试:给新岗位做一次真实的上岗就绪判定,对照三个条件——角色在岗、已建档且启用了非空提示词版本、期望技能已装配。结论会写回测试记录。
- 留痕:写一条变更记录,带"回滚点"。后悔了可以一键回退——新 Agent 会被停用、组织节点被撤销。
如果扩编中途失败(比如技能装配出错),整个流程会回滚,建议退回到"已确认"状态,你可以修完问题再点一次。它不会留下半拉子工程。
第四块:能力开启
卡片标题「能力开启(已开启 X / 阶段推荐 Y)」,带一条进度条。下面是能力清单,每项显示:名称、阶段标签、已开启 / 未开启。
ZY 引擎的能力是打过分阶段标签的:
| 能力梯队 | 典型能力 | 推荐开启阶段 |
|---|---|---|
| 核心必备 | Agent 执行 / AI 对话 / 知识库 / 账本 / 自动构建部署 | 起步期(项目创建即启用) |
| 获客与运营 | 营销自动化 / 邮件 / SEO / 通知 / 报告 / 备份 / 合规审查 | 成长期 |
| 规模化 | A/B 测试 / 多语言 / CRM / 合同发票 / 知识图谱 / 竞品监控 / 跨项目迁移 | 规模化期 |
系统会针对"到了该开但还没开"的能力生成建议。注意两点:能力就绪不等于自动开启,路径永远是"检测需求 → 建议(含成本)→ 你确认 → 生效";同时你可以随时手动开关任意能力,建议只是参考。
第五块:定量调控(八维)
这是"不要一刀切的开关,而要连续调节"思想的落地。八条维度:
| 维度 | 含义 | 范围 | 能否调 |
|---|---|---|---|
| 预算 | 每天能花多少钱 | $0.5–500/天 | 可调 |
| 自主权限 | 给 AI 多大自主权(0–100 分) | 0–100 | 可调 |
| 优化频率 | 多久做一次角色优化 | 关闭 / 月 / 周 / 日 / 实时 | 可调 |
| 优化强度 | 优化的力度 | 浅 / 标准 / 深 | 可调 |
| 模型等级 | 用 flash / normal / pro 哪档模型 | flash / normal / pro | 只读 |
| 并发数 | 同时能跑几个任务 | 0–10 | 可调 |
| 技能数 | 角色平均技能数量 | 1–1000 | 只读 |
| 汇报频率 | 多久给你汇报一次 | 关闭 / 周 / 日 / 每任务 | 只读 |
为什么有三个只读?因为它们的值由底层引擎实时决定(模型等级来自模型路由网关、技能数来自技能库装配、汇报频率来自报告引擎),人为硬改会造成"视图和实际不一致"。系统干脆不让你改,免得你改了一个假数字。只读维度你点它会明确报错,不会假装成功。
阶段切换:从"起步"走到"成长"
点页面右上角 阶段切换,弹出「阶段切换」窗口,顶部有一段重要的说明(界面原文):
字段有两个:「目标阶段」(下拉,每个选项后面带它的组织形态,如"成长期(小组分工)")、「岗位集(可选,留空使用阶段推荐默认岗位)」(输入 role_key 后回车添加)。按钮是 回退上次切换 取消 确认切换。
提交后,系统会批量补建这个阶段缺的岗位,有三点细节和上面那句"校验"的措辞要对上:已经存在的岗位会自动跳过(不会重复建);草稿里的技能如果在技能库里找不到,会跳过装配、并给你一条人工提醒(不会因此让整条切换失败);预算不足只会预警,不会阻断这次切换。回退的确认文案是「确定回退最近一次阶段切换?组织节点与阶段状态将恢复。」
四阶段模型:你现在在哪一档
这是本章最值得记住的一张表。它是"你的业务规模 → 该配多大规模的组织 → 大概花多少钱"的对照表。成本一列是估算参考(含 token、算力、媒体等 AI 运行成本),不是账单。
| 阶段 | 对标规模 | 组织形态 | 典型月成本(估算) | 优化频率 | 预算策略 |
|---|---|---|---|---|---|
| 起步期 startup | 0→1(约 2 人公司) | 一人全能 | ~$10–30 | 按需触发 | 固定预算 + 硬熔断 |
| 成长期 growth | 1→10(约 10 人团队) | 小组分工 | ~$50–150 | 每周轻度 + 每月复盘 | 基础预算 + 弹性 |
| 规模化期 scale | 10→100(50–200 人) | 部门建制 | ~$200–800 | 每日监控 + 每周优化 | 动态预算 + ROI 调度 |
| 成熟期 maturity | 100+(500+ 人) | 事业部自治 | ~$500–2000+ | 实时自适应 | 多预算池 + 全局 ROI |
四个阶段的组织形态各自是什么样:
- 起步期"一人全能":1 个全能 Agent 兼任 CEO、开发、运营,跑通"想法 → 成品 → 上线"的最小闭环。
- 成长期"小组分工":CEO + 研发 + 营销 + 客服,验证产品与市场匹配、开始获客。
- 规模化期"部门建制":CEO + 研发 / 营销 / 销售客服 / 运营四大部门,部门内再细分岗位。
- 成熟期"事业部自治":CEO + 多事业部完整团队 + 中台 Agent(知识 / 技术 / 数据中台),技能按需装配。
升级看什么数据
升级不看感觉,看数据。每个阶段有一组"毕业标准"(升级规则),命中率达到一定比例才算达成:
| 要升级到 | 关键门槛(示例) |
|---|---|
| 成长期 | 任务完成数 ~50、营收 ~5000 |
| 规模化期 | 任务完成数 ~200、营收 ~50000、活跃 Agent 数 ~4、知识文档数 ~50 |
| 成熟期 | 任务完成数 ~1000、营收 ~500000、活跃 Agent 数 ~10 |
| (终态) | 成熟期没有升级阈值,它是终点 |
这些数字是内置的默认阈值,实际以你界面「判定证据」表里显示的"阈值"为准。判定逻辑是:命中率达到较高比例(约六成)且最小数据源(营收、任务完成数)有命中,才算"已达成";命中约四成算"接近"。
关于"自动管理"的四个常见疑问
它会自己花钱招人吗?
不会。只有你点了「确认」,扩编才会真正发生,而且扩编前会做「预算覆盖校验」——如果预算不够覆盖新增角色的估算月成本,这一步就会拦下来。系统也会在建议里明确标出"扩编后总成本变化",让你在点确认之前就知道要多花多少。
我不管它,它会一直提醒我吗?
不会。同类型的建议有冷却节流机制:你点一次「暂缓」,冷却期内(默认 7 天)它就不再重复提示。系统会尽量把建议合并打包,而不是一条一条轰炸你。这也是"注意力管理"的一部分——组织越大,越需要控制打扰频率。
它建议加的人,我不满意怎么办?
三种办法:一是点「确认」时修改字段(岗位名、职责边界、技能草稿、成本估算都可以覆盖后再落地);二是点「拒绝」并写明原因,这条会留档;三是先让它落地,如果效果不好,再用变更记录一键回滚。系统不强制你接受任何建议。
阶段升级会不会把我的组织架构全推翻?
不会。阶段切换的动作是"补建缺失岗位",已经存在的岗位会被跳过,不会重建、不会清空你已有的配置。切换前系统还会做一次快照备份;如果你觉得不合适,点「回退上次切换」,组织节点和阶段状态都会恢复到切换前。它是渐进的、可逆的。
九、人 + Agent 的混合团队怎么配
ZY 引擎服务的不是"AI 全权接管",而是"人 + AI 混合团队"。人的位置在哪,决定了你该配哪些 Agent。
四种角色分工
你(负责人)
定方向、批预算、拍板加不加人。对应"方向负责人 / 项目负责人"。
团队成员(人)
处理需要线下完成的事、审核关键节点、维护知识。
管理者 Agent
拆任务、分活、盯进度、验收。不下场执行。
员工 Agent
领域专家,真正把活干出来。
补一句边界:目前这条约束主要是在界面上把住的——给 Agent 编辑权限时,管理权限那一组会禁用、点不了(详见第 14 章第二节的说明)。
三档配置建议
| 你的情况 | 建议配置 | 为什么 |
|---|---|---|
| 一个人创业,刚开始 | 1 个全能员工(general_executor)+ 可选 1 个管理者 | 起步期"一人全能"最省钱,先跑通闭环再谈分工 |
| 小团队,开始获客 | 管理者 1 个 + 员工 3–5 个(研发 / 营销 / 客服) | 成长期"小组分工",每个岗位对应一条业务线 |
| 多产品线,规模化了 | 管理者 + 按部门细分岗位,用组织进化建议来加 | 规模化期"部门建制",让系统提示缺哪个岗,你只做确认 |
- 先建"干活的人",跑通一个任务,再加管理者
- 岗位从模板库里挑,别自己硬造名字
- AI 建议先看"为什么(证据)"再点确认
- 新 Agent 上线后盯几天返工率
- 别一上来就建 10 个 Agent,起步期纯属浪费
- 别跳过成本估算就点"确认",扩编是持续花钱
- 别给新 Agent 一口气绑十几个技能
- 别指望系统自己加人,它只会建议、不会擅自决定
十、本章小结与下一步
把这一章压缩成六句话:
- Agent 是"人",任务 是"活"。人分两类:管理者(只协调不下场)和员工(专家,负责执行)。
- 三要素:岗位(专家)、技能、连接器。齐了才算配齐一个 Agent。
- 智能体中心四个页签:组织(建人配技能)、任务(派活)、配置(运行参数)、运行(看谁在跑、花了多少)。
- 岗位模板库按项目类型预置:软件开发 / 电商运营 / 内容创作 / 智能制造各一套,通用类型回退到"项目经理 + 通用执行者"。
- 组织进化引擎能自动感知 + 建议 + 一键落地,但"要不要加人"永远由你拍板。升级看数据不看感觉,且可回退。
- 四阶段:起步(~$10–30)→ 成长(~$50–150)→ 规模化(~$200–800)→ 成熟(~$500–2000+)。成本是估算,不是账单。
下一步:人和队伍都配好了,接下来看"活是怎么派下去、一轮一轮转起来的"。请读 第 09 章 · 自动运营:任务、轮次与验收。如果对"智能体怎么把一个复杂软件功能做出来"更感兴趣,可以直接跳到 第 10 章 · 软件功能的开发与修改。
附录 A · 预置岗位模板全表
这张表是引擎内置的全部岗位模板(来自代码,非编造)。建团队时可直接对照。连接器一列是"该岗位运行时按需绑定的外部系统"。
软件开发(software)
| 岗位 key | 名称 | 角色描述 | 职责边界 | 人工红线 | 技能 | 连接器 |
|---|---|---|---|---|---|---|
| manager | 项目经理 | 识别任务、组织分配、验收协调;不下场执行具体编码 | 仅做任务拆解、分配、进度跟踪与质量验收 | 不得直接修改代码;不得绕过质量验收流程 | task_decomposition, progress_tracking | 无 |
| fullstack_dev | 全栈开发专家 | 前后端功能开发、数据库设计、API 实现 | 仅实现被分配的子任务;不得擅自变更架构 | 不得直接修改生产数据库结构;不得部署未经审核的变更 | coding_frontend, coding_backend, db_design | git_repo |
| test_expert | 测试专家 | 编写和执行单元 / 集成 / E2E 测试,回归测试 | 仅编写测试代码与报告缺陷;不修改业务代码 | 不得跳过失败测试;不得伪造测试覆盖率 | test_unit, test_integration, test_e2e | 无 |
| devops_expert | 运维专家 | 部署、CI/CD、监控、日志、故障排查 | 仅做运维操作;变更前必须经管理者审核 | 不得直接操作生产数据库;不得关闭监控告警 | ci_cd, monitoring, incident_response | ci_cd_trigger |
电商运营(ecommerce)
| 岗位 key | 名称 | 角色描述 | 职责边界 | 人工红线 | 技能 | 连接器 |
|---|---|---|---|---|---|---|
| manager | 运营总监 | 整体运营策略、资源调度、KPI 管理 | 仅做策略与分配;不直接执行营销活动 | 不得擅自变更定价;不得承诺超出预算的支出 | strategy_planning, budget_management | 无 |
| marketing_expert | 营销获客专家 | 营销活动策划、获客渠道运营、广告投放 | 执行被分配的营销活动;预算超限必须上报 | 不得投放未审核的广告素材;不得超出授权预算 | campaign_planning, ad_targeting, content_copy | feishu_msg, email_sender |
| customer_service | 客服专家 | 客户咨询响应、售后问题处理、满意度跟踪 | 按 SOP 处理客户问题;超权限问题升级 | 不得私自退款;不得承诺超出政策的赔偿 | customer_communication, issue_resolution | feishu_msg |
| data_analyst | 数据分析师 | 销售 / 运营数据分析,提供决策支持报告 | 仅做数据分析与报告;不修改业务数据 | 不得伪造数据;不得泄露客户敏感信息 | data_query, reporting, data_viz | 无 |
内容创作(content)
| 岗位 key | 名称 | 角色描述 | 职责边界 | 人工红线 | 技能 | 连接器 |
|---|---|---|---|---|---|---|
| manager | 内容总监 | 内容规划、选题、团队协调、质量把控 | 仅做规划与审核;不直接下场创作 | 不得发布未经审核的内容;不得违反平台合规 | content_planning, editorial_review | 无 |
| copywriter | 文案专家 | 文案撰写、脚本创作、品牌故事 | 按选题方向创作;发布前必须经审核 | 不得抄袭;不得发布虚假宣传内容 | writing_copy, storytelling, brand_voice | email_sender |
| design_expert | 设计专家 | 视觉设计、品牌 VI、海报 / 封面制作 | 按需求产出设计稿;品牌 VI 变更需审核 | 不得擅自变更品牌标识;不得使用未授权素材 | graphic_design, brand_identity | 无 |
| seo_expert | SEO 专家 | 关键词研究、内容优化、外链建设 | 按 SEO 策略执行;不得使用黑帽手段 | 不得使用关键词堆砌;不得购买垃圾外链 | keyword_research, onpage_seo, link_building | 无 |
智能制造(manufacture)
| 岗位 key | 名称 | 角色描述 | 职责边界 | 人工红线 | 技能 | 连接器 |
|---|---|---|---|---|---|---|
| manager | 生产总监 | 生产计划、资源调度、质量管控 | 仅做计划与协调;不直接操作生产设备 | 不得绕过安全规程;不得隐瞒质量事故 | production_planning, quality_control | feishu_msg |
| process_engineer | 工艺工程师 | 工艺优化、SOP 制定、产能提升 | 工艺变更需测试验证后实施 | 不得擅自修改关键工艺参数 | process_optimization, sop_authoring | 无 |
通用(general,回退模板)
项目类型为"通用业务"或未识别时,没有专属模板库,系统回退到下面两人最小集:
| 岗位 key | 名称 | 角色描述 | 职责边界 | 人工红线 | 技能 |
|---|---|---|---|---|---|
| manager | 项目经理 | 负责识别任务、组织分配、验收协调 | 仅做管理与协调 | 不得越权操作 | task_decomposition |
| general_executor | 通用执行者 | 执行被分配的具体任务 | 按管理者指令执行 | 不得自行接受未授权的任务 | (无预置技能) |
附录 B · 技能清单:引擎里有哪些技能 ID
前面说过,技能库没有出厂种子,它是用出来的。但岗位模板里已经引用了一批标准的技能 ID——这些就是"引擎期望你会用"的技能命名。你把它们建进技能库,就能和模板直接对上。
下面按用途归类,列出模板引用到的全部技能 ID:
| 用途 | 技能 ID | 中文含义(便于起名) |
|---|---|---|
| 管理 | task_decomposition | 任务拆解 |
| progress_tracking | 进度跟踪 | |
| 开发 | coding_frontend | 前端编码 |
| coding_backend | 后端编码 | |
| db_design | 数据库设计 | |
| 测试 | test_unit | 单元测试 |
| test_integration | 集成测试 | |
| test_e2e | 端到端测试 | |
| 运维 | ci_cd | 持续集成 / 交付 |
| monitoring | 监控 | |
| incident_response | 故障响应 | |
| 运营管理 | strategy_planning | 战略规划 |
| budget_management | 预算管理 | |
| 营销 | campaign_planning | 营销活动策划 |
| ad_targeting | 广告定向投放 | |
| content_copy | 营销文案 | |
| 客服 | customer_communication | 客户沟通 |
| issue_resolution | 问题解决 | |
| 数据分析 | data_query | 数据查询 |
| reporting | 报表 | |
| data_viz | 数据可视化 | |
| 内容管理 | content_planning | 内容规划 |
| editorial_review | 内容审核 | |
| 创作 | writing_copy | 文案撰写 |
| storytelling | 故事化表达 | |
| brand_voice | 品牌语调 | |
| 设计 | graphic_design | 平面设计 |
| brand_identity | 品牌视觉(VI) | |
| SEO | keyword_research | 关键词研究 |
| onpage_seo | 站内优化 | |
| link_building | 外链建设 | |
| 生产制造 | production_planning | 生产计划 |
| quality_control | 质量控制 | |
| 工艺 | process_optimization | 工艺优化 |
| sop_authoring | SOP 编写 |
附录 C · Agent 配置字段字典
「Agent 运行配置」(智能体中心 → 配置页签)的新建/编辑弹窗字段全集,逐条说明:
| 字段 | 类型 | 必填 | 取值范围 / 默认 | 作用 | 能否改 |
|---|---|---|---|---|---|
| Agent 名称 | 文本 | 是 | 任意 | 标识这是给哪个 Agent 的配置 | 可改 |
| 角色 | 文本 | 否 | 角色标识,如 fullstack_dev | 绑定岗位 | 可改 |
| 运行模式 | 下拉 | 是 | 前台 foreground / 后台 background / 定时 cron / 事件监听 event_listen | 决定什么时候跑 | 可改 |
| Cron 表达式 | 文本 | 否 | 标准 5 段 Cron,如 0 * * * * | RunMode=cron 时生效 | 可改 |
| 事件触发 | 多选 / 可自定义 | 否 | 通配符,如 message.*、approval.*、task_result、alert.*、report.*、deploy.*、review.* | RunMode=event_listen 时生效 | 可改 |
| 系统提示词 | 多行文本 | 否 | 任意 | 这个 Agent 的工作指令 | 可改,最值得花时间 |
| 工具列表 | 多选 | 否 | 留空 = 全部可用 | 限制它只能用哪些工具 | 可改 |
| Token 上限 | 数字 | 否 | 默认 300000 | 单次运行的 token 天花板 | 可改 |
| 自动启动 | 开关 | 否 | 关 / 开 | 服务启动时是否自动拉起 | 可改 |
| 启用 | 开关 | 否 | 关 / 开 | 这条配置是否生效 | 可改 |
| 版本 | 只读数字 | — | 递增 | 同一配置的修改历史 | 系统维护 |
配置还能通过「导入 XML」批量创建,导入的弹窗字段只有两个:文件路径、XML 内容(二选一)。同一 name+role 重复导入会变成版本 +1,不会重复建。
Agent 本身的字段(新建 Agent 弹窗)
| 字段 | 必填 | 取值 | 默认 |
|---|---|---|---|
| 名称 | 是 | ≤128 字 | — |
| 岗位角色 | 是 | 模板的 role_key 或自定义 | — |
| 类型 | 是 | manager / worker | worker |
| 上级管理者 | 否 | 某管理者的 agent_id | 空(不挂靠) |
| 负责人 | 是 | 人类用户 ID 或上级管理者 ID | — |
| 角色描述 | 否 | 文本 | 空 |
| 职责边界 | 否 | 文本 | 空 |
| 人工红线 | 否 | 文本 | 空 |
附录 D · 组织进化建议类型与处置手册
收到一条 AI 建议时,先看类型,再决定怎么处置。
| 建议类型 | 界面显示 | 它在说什么 | 点确认后 | 建议处置 |
|---|---|---|---|---|
| role_add | 增员 | 某个岗位缺人(新业务线没有对应角色) | 建角色 → 配技能 → 上岗 | 先看理由与成本,确实缺就确认 |
| scale_out | 扩容 | 某岗位任务排队太多,一个人干不过来 | 建一个并行实例(名字自动 -2、-3) | 确认前想清楚:是长期忙还是临时高峰 |
| skill_attach | 技能装配 | 某项能力到了该开启的时候 | 确认即生效(不建角色) | 风险最低,一般可以直接确认 |
| stage_upgrade | 阶段升级 | 数据够了,可以进入下一阶段 | 批量补建缺失岗位 + 更新阶段 | 影响面最大,务必看完证据再决定 |
三种处理方式怎么选
| 操作 | 按钮 | 什么时候用 | 后果 |
|---|---|---|---|
| 确认 | 确认 | 认可,且现在就要落地 | 系统自动扩编 / 装配 / 升级,可回滚 |
| 暂缓 | 暂缓 | 认可但时机不对(比如预算紧张) | 冷却 N 天(默认 7),期内不再重复提示 |
| 拒绝 | 拒绝 | 不认可这个判断 | 留档原因;若缺口仍存在,会以新建议重提 |
建议状态一览
待确认 pending → (你操作后)已确认 accepted → 已应用 applied;或 已拒绝 declined / 暂缓 deferred / 已过期 expired。注意:点确认后接口回给你的文案恒为"已确认",而实际落地成功后的状态是"已应用"。想确认到底落没落地,刷新一下建议列表看状态。
扩编异常与处置
| 现象 | 可能原因 | 怎么处理 |
|---|---|---|
| 确认后状态仍是"已确认" | 落地中途失败(技能或预算) | 看提示,补齐技能 / 调整预算后重新确认 |
| 技能装配被跳过 | 技能草稿里的 skill_id 在技能库里不存在 | 先在技能库补建该技能,再重试 |
| 角色名自动变成"某某-2" | 扩容建议(scale_out)遇到同名角色 | 正常现象,是并行实例的防撞车机制 |
| 报"角色名 X 已存在,禁止重复扩编" | 新增岗位建议(role_add)在同一分类下已有同名角色;或双击确认的第二次 | 正常拦截:说明这个岗位已经建好了。确认是不是重复建议,或直接去角色列表找到它 |
| 角色建好了却被停用,且多出一条人工节点 | 上岗就绪判定未通过(缺启用版本 / 技能没装配上) | 去人工节点看"扩编上岗测试失败"的原因,补齐后重试;处理完再启用该角色 |
| 想撤销刚扩的编 | — | 用变更记录的一键回滚:停用新 Agent、撤销组织节点 |
附录 E · 一个 Agent 的提示词范例
「系统提示词」是你最该花时间的地方。下面给一个"营销获客专家"的可复制范例。你可以整段复制进配置 → 系统提示词,把方括号里的内容换成你自己的。